1. Technical Field
The present invention relates in general to the distributed computing. More specifically, the present invention relates to the field of registration in distributed transaction processing computing.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time computers have become indispensable in many fields of human endeavor including engineering design, machine and process control, and information storage and access. In the early days of computers, companies such as banks, industry, and the government would purchase a single computer which satisfied their needs, but by the early 1950""s many companies had multiple computers and the need to move data from one computer to another became apparent. At this time computer networks began being developed to allow computers to work together.
Computer networks are capable of performing jobs that no single computer could perform and they allow low cost personal computer systems to connect to larger systems to perform tasks that such low cost systems could not perform alone. In order for computer systems to cooperate in a network to perform some complex job, software must be developed which efficiently delegates parts of the chore or tasks to different computers in the network.
The International Standards Organization (ISO) has defined an ISO Distributed Transaction Processing (DTP) standard to support the synchronization and co-ordination of distributed applications to ensure that transactions can be reliably completed on multiple open systems. X/Open is an industrial standards organization that has defined a reference module for the OSI DTP. X/Open has also defined application program interfaces and system interfaces between system components defined in the model.
The X/Open model defines the various system elements that work together to perform distributed transaction processing. In particular, the X/Open model defines Transaction Managers (TMs) and Resource Managers (RMs) that work together, along with other elements, to facilitate distributed processing. Transaction Managers are the components that assign identifiers to transactions, monitor the progress of transactions, and take responsibility for transaction completion and coordinating failure recovery. Resource Managers are the components that provide access to resources, such as database systems. Typically, the Transaction Manger coordinates the start and completion of the global transactions of each participating Resource Manager. For example, when an application calls the Transaction Manager to start a global transaction, the Transaction Manager assigns a global transaction ID and informs the Resource Manager about the new transaction branch. After the application performs operations on the Resource Manager within the global transaction, the Transaction Manager calls the Resource Manager to either commit or rollback the transaction branch. Also, if failure recovery is needed the Transaction Manager recalls the failed transaction from the Resource Manager and continues to complete the failed transaction.
In order for Transaction Managers and Resource Managers to work together to facilitate distributed processing, the X/Open model requires that all Resource Managers register to the Transaction Manager before the distributed transaction is begun. This registration makes the Resource Manager known to the Transaction Manager, such that they can work together to complete transactions.
Currently, some systems use a registration system typically referred to as xe2x80x9cstatic registration.xe2x80x9d In static registration, all Resource Managers are required to the Transaction Manager before any distributed transaction occurs. In particular, because there is no efficient way for a Transaction Manager to dynamically know what Resource Managers are going to be involved in a particular distributed transaction, current static registration methods require that all Resource Managers register with the Transaction Manager when the Transaction Manager is constructed. This static registration is required even if a particular Resource Manager will not participate in an upcoming distributed transaction.
When a distributed transaction is then started, the Transaction Manager must inform all registered Resource Managers to start a transaction even though some of those Resource Managers will not be involved in the current transaction.
The requirement that all Resource Managers register beforehand with the Transaction Managers and that all Resource Managers, even those not participating in a transaction, be notified when a transaction starts results in transactional complexity that causes delay and other significant inefficiencies. In particular, if all the Resource Managers must register to the Transaction Manager even though some of those Resource Managers are not involved in the current transaction, then each transaction causes unnecessary flows. For example, if there are two Resource Managers involved in the current transaction and there are four Resource Managers registered to the Transaction Manager, then there will be six extra flows per transaction (i.e., two extra xa_start, two extra xa_end, and two extra xa_prepare). Additionally, these extra flows may involve distributed processes that can cause even more overhead.
For this reason there has recently been other attempts to utilize xe2x80x9cdynamic registrationxe2x80x9d of the Resource Managers. Unfortunately, some of these techniques have also had significant drawbacks. One significant drawback is the loss of execution control by the Transaction Manager. In particular, the Transaction Manager does not have control over the starting of transactions as it does when static registration is used. Instead, the Transaction Manager waits for the Resource Manager to inform the Transaction Manager that it is involved in a new transaction. In a normal case, this can be an efficient way to let the Resource Manager participate in a transaction. However, in some cases a new transaction will be instantiated by the Resource Manager in the process of ending a global transaction and an unpredictable error will occur.
There thus remains no effective way to register Resource Managers with Transaction Managers in an X/Open distributed transaction system Thus, what is a needed is a mechanism providing an efficient way to use register and control the transaction involvement of Resource Managers without requiring unnecessary Resource Manager involvement.
The preferred embodiment provides an improved system and method for registration of Resource Managers with Transaction Managers in an X/Open distributed processing environment. The preferred system and method creates and stores a transactional resource in a container when the first execution method goes to the Resource Manager. The transactional resource represents the Resource Manager to the Transaction Manager. The transactional resource uses X/Open static registration procedures to inform the Resource Manager about the new transaction. The transactional resource is then registered to the Transaction Manager. In this way, only those Resources Managers that are involved in a transaction are registered and made known to registered to the Transaction Manager. Additionally, because static registration procedures are used, the Transaction Manager maintains control of the transaction.
Additionally, in the preferred embodiment the transactional resource implements the commit control interfaces on behalf of the Resource Manager. Thus, when an application decides to a commit (or rollback) a transaction, the commit (or rollback) command will call the transactional resource and the transactional resource will call the Resource Managers for this transaction with the appropriate command.
In the preferred embodiment, the transactional resource is created in and by a container that additionally stores information which relates to corresponding Resource Managers. When a transaction is started that operates on a business object in the container, the container will create a transactional resource that will represent the Resource Manager to the Transaction Manager for this transaction. The container will then register the new transactional resource to the Transaction Manager. The Transaction Manager then informs the Resource Manager about starting a new transaction indirectly via the transactional resource using the static registration technique.
This registration process will need to occur once for each transaction, only on the first execution of a method on the business object which resides in the container for this Resource Manager. Furthermore, because only those transactional resources that represent Resource Managers involved in the transaction are registered with the Transaction Manager, only those Resource Managers participating in the transaction will be involved by the Transaction Manager. Stated another way, the Transaction Manager selectively learns which resources are involved in a current transaction, and thus only has to interact with those resources actually involved in the current transaction.
Thus, the preferred embodiment provides that a registration method and mechanism that minimizes unnecessary flows by limiting calls to only those resources that are involved in transactions while allowing the Transaction Manager to retain control of the transaction. In particular, the preferred embodiment allows the use of X/Open static registration techniques to facilitate a selective registration that does not suffer from the limitations of previous X/Open dynamic registration methods.
The foregoing and other features and advantages of the present invention will be apparent from the following more particular description of the preferred embodiment of the invention, as illustrated in the accompanying drawings.